home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group98c.txt
/
000122_icon-group-sender _Thu Dec 10 09:27:44 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
2KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA07759
for icon-group-addresses; Thu, 10 Dec 1998 09:26:14 -0700 (MST)
Message-Id: <199812101626.JAA07759@baskerville.CS.Arizona.EDU>
Date: Thu, 10 Dec 1998 15:00:08 +1300 (NZDT)
From: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
To: evans@gte.net, icon-group@optima.CS.Arizona.EDU
Subject: Re: Past Keyword / Coexpr Help
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
What everyone is missing about procedures-that-do-the-job is the speed
consideration. Think about embedding either procedure in a deep inner
loop of some kind. At that point, it is much preferable to have a
keyword, which
(a) avoids any overhead of procedure calling,
(b) doesn't have to both find and then match the same text
(redundancy),
(c) simplifies the code readability
Concerning (a), just what _is_ the procedure call overhead?
It's only worth worrying about if
(1) it is large compared with the useful work done (is it large?)
(2) the compiler is unable to expand calls to it in-line (is it unable?)
(3) there's nothing else going on in that loop with worse overheads.
Concerning (c), I note that realistic programming languages have to deal
with huge libraries these days. Not the current UNIX interface (the
Single UNIX Specification one) but the _previous_ one was called Spec1170
because it had 1170 functions in the interface. Windows has even more.
If procedure calls are unreadable, then heaven help us.
Concerning (b), is this the _only_ situation where that problem comes
up? I don't think so. Just how many keywords are we going to need if
we try to solve them all by keywords?